FunnelFlux tiene dos identificadores únicos, que se detallan a continuación.
Hit IDs
Los Hit IDs se generan para cada vista a un nodo por cualquier visitante.
Son el ID más único en nuestro sistema. Cada nodo visitado (incluso los rotadores) genera un hit ID y estos son los eventos crudos que almacenamos en nuestra base de datos de análisis. Se pueden pasar en la URL usando el token {hit}.
Informes
Los Hit IDs solo están disponibles en la página de eventos crudos
En la página de eventos crudos se muestran en la columna "Hit ID" y no están disponibles en los informes regulares debido a su alta cardinalidad (es decir, nuestra base de datos de análisis agregando por estos es una consulta de muy bajo rendimiento que debe evitarse).
Tenga en cuenta que la página de eventos crudos solo devuelve las 1000 filas más recientes de cualquier consulta -- para evitar el problema de rendimiento mencionado anteriormente.
Cuando se utiliza el atributo de informe "recorrido del visitante", son estos hit IDs los que nos permiten crear un árbol de nodos del recorrido del usuario a través de los embudos.
Seguimiento de Conversiones
La forma más común de seguimiento de conversiones es usar una URL de postback con nuestro hit ID, a saber:
https://USER_DOMAIN/pb/?hit=HIT_ID&rev=REVENUE&tx=OPTIONAL
El hit ID se genera al ver una página, por lo que si se redirige a una oferta, es el hit ID pasado con {hit} en esa URL de oferta el que representará la vista a esa página, y por lo tanto el ID a convertir.
Todos los hit IDs de ofertas que son elegibles para convertir terminarán con una "h".
Las conversiones en JavaScript pueden especificar un hit ID, que será exacto y no se necesitarán otros datos. Sin embargo, es poco probable que uno capture y envíe un hit ID correcto al JS del lado del cliente, ya que el hit a convertir tiende a ser de la página anterior.
Si puede pasar hits de una página a la siguiente, probablemente podría usar una solicitud GET a la URL de postback, con ese hit ID, para convertir el hit en lugar de usar JS.
Visitor IDs
Estos tienen el token {visitor} y son un identificador a nivel de sesión para un usuario.
Nuestro sistema creará estos para cualquier visitante que llegue nuevo y automáticamente añadirá &vid={visitor} a todos los destinos de redirección, para asegurar que la página resultante (a menudo una landing/oferta con nuestro JS) pueda rastrear al usuario sin problemas.
Nuestra cookie almacena este valor VID y es el valor más importante para asegurar un seguimiento fiable de los usuarios. Por eso nuestras funciones auxiliares de JS reescriben las URLs para incluirlo + lo inyectan en las URLs de acción.
Almacenamiento en Caché y Almacenamiento
Los datos de sesión del usuario se almacenan en una caché centralizada a la que acceden nuestros servidores edge regionales durante el procesamiento de redirección. El objeto de sesión almacena todo el historial de navegación del embudo del usuario junto con todos los parámetros de URL que lo acompañan desde la fuente de tráfico, o que fueron inyectados manualmente en las URLs de acción/entrada.
Estos Visitor IDs tendrán el prefijo a, e o u para las visitas localizadas en Asia, Europa y EE.UU., respectivamente. Esto permite que otros edges que reciban un ID fuera de región lo busquen en la caché correcta, lo cual es importante en casos donde un usuario puede cambiar de ubicación, usar una VPN a mitad del recorrido, o cuando sistemas de terceros envían eventos de conversión del lado del servidor usando el valor VID.
Las sesiones tienen una caducidad predeterminada de 7 días a menos que se declaren embudos vinculados en la configuración del embudo.
Datos de URL
Notablemente, todos los datos de URL se almacenan en el objeto de sesión, pero solo aquellos campos nombrados en la configuración de la fuente de tráfico se guardarán en la base de datos de análisis. Por lo tanto, es posible pasar datos temporales a las URLs y hacia adelante a páginas/ofertas usando este objeto de sesión.
En el constructor de embudos > un nodo de página > configuración adicional, el interruptor de parámetros de URL acumulados vuelca los datos de URL del objeto de sesión en la URL de la página de destino.
Seguimiento de Conversiones
Las conversiones se pueden enviar a través de nuestra URL de postback usando tanto el visitor ID como el hit ID.
Los Hit IDs son el ID más específico en nuestro sistema y hacen referencia a una vista específica de un nodo específico por un solo visitante -- por lo tanto, solo se necesita el hit ID.
Para el visitor ID, la página que vieron también es información importante, ya que el visitor ID solo identifica la sesión del usuario, no qué oferta convertir.
Por lo tanto, esto funcionará como una URL de postback:
https://USER_DOMAIN/pb/?vid=VISITOR_ID&p=PAGE_ID&rev=REVENUE&tx=OPTIONAL
Si no se proporciona un ID de página, se convertirá la vista de oferta más reciente para ese visitante (lo cual puede no ser el resultado deseado).
Las conversiones en JavaScript idealmente también incluyen vid en su código ya que el JS en última instancia depende de un seguimiento coherente del VID.
Esto se puede inyectar manualmente, aunque el JS obtendrá fácilmente esta información de la URL actual, la cookie y el referente, si están disponibles. Si se puede inyectar dinámicamente, es mejor hacerlo.
Si se usa el VID, también es ideal enviar el ID de página (el atributo p), y evitar enviar el hit ID en combinación con el VID ya que son métodos competitivos, siendo el último más específico.
Informes
En la página de eventos crudos se muestran en la columna "session ID" y no están disponibles en los informes regulares debido a su alta cardinalidad (es decir, nuestra base de datos de análisis agregando por estos es una consulta de muy bajo rendimiento que debe evitarse)
Embudos vinculados y conversiones indirectas
Una característica de FunnelFlux es la capacidad de atribuir ingresos/conversiones indirectamente a un embudo anterior.
Esto se logra declarando el primer embudo al segundo embudo como un "embudo vinculado" en su configuración avanzada.
Cuando hay embudos vinculados presentes, el tiempo de caducidad de la sesión se extiende a 30 días.
Cuando ocurre una conversión en el embudo B, el procesador de conversiones inspeccionará los datos de sesión del usuario, verá el embudo A original que ha sido "vinculado" al embudo B, y adicionalmente pasará una conversión indirecta.
Estos datos de conversión/ingresos son visibles en los informes y permiten a los usuarios ver el valor extendido de los usuarios provenientes de embudos posteriores.
Un buen ejemplo es un embudo de opt-in, donde los usuarios están rastreando el costo de los leads de una campaña publicitaria. Ese embudo puede vincularse a un embudo de correo electrónico, donde un usuario está generando enlaces para usar en secuencias de correo electrónico. Los correos electrónicos pueden crear conversiones, que se rastrean independientemente dentro del embudo de correo electrónico, pero también notifican al embudo de opt-in original de los ingresos indirectos que creó.
Para que esta característica funcione, el valor VID del usuario DEBE pasarse a las URLs de entrada utilizadas en el embudo B. Usualmente añadiendo manualmente algo como ..&vid=%SUBSCRIBER_FF_VID% a una URL, donde el usuario capturó nuestro VID durante el opt-in y lo almacenó en algún atributo de perfil de CRM.